오브젝트 (1)

ordilov / 2022. 3. 19

객체지향의 첫 걸음은 클래스가 아니라 객체를 바라보는 것입니다. 두 번째 걸음은 객체는 독립적인 존재가 아닌 협력하는 공통체로 봅니다. 세 번째 걸음은 객체들에게 얼마나 적절한 역할과 책임을 부여하느냐입니다. 마지막 걸음은 앞의 개념들을 프로그래밍 언어 틀에 담아내는 것입니다.

프로그래밍 패러다임을 통해 개발자 공동체가 동일한 프로그래밍 스타일과 모델을 공유합니다.

"이론이 먼저일까, 실무가 먼저일까?" 아무것도 없는 상태에서 이론보다는 실무를 관찰한 결과를 바탕으로 이론을 정립합니다. 소프트웨어도 실무에서 반복적으로 적용되된 기법들이 이론화한 것들이 대부분입니다. 따라서 이론처럼 개념을 먼저 보는 것보다 코드 그 자체로 이해하는데 더 도움이 됩니다.

• 실행 중에 제대로 동작
• 변경을 위해 존재
• 코드를 읽는 사람과 의사소통

제대로 동작하더라도 변경이 용이하지 않고 읽기 어려우면 고칠 필요가 있습니다.

객체 사이의 의존성이 있는 경우 변경에 영향을 받을 수 있습니다. 최소한의 의존성을 유지하면서 불필요한 의존성을 제거하는 것이 목표입니다. 의존성이 과한 경우를 가리켜 결합도가 높다고 말합니다. 결합도를 낮추기 위해선 객체들을 자율적인 존재로 만들어야 합니다.

자율적으로 만들면서 객체 내부의 세부적인 사항을 감추는 것을 캡슐화라고 합니다. 캡슐화를 통해 객체 내부 접근을 제한하면 객체와 객체 사이 결합도를 낮출 수 있습니다.

객체가 의존하는 것은 인터페이스에만 의존하고 구현은 인스턴스로 제공합니다. 인터페이스만 공개하는 것은 결합도를 낮추고 변경하기 쉬운 코드의 가장 기본적인 설계 원칙입니다.

객체가 밀접하게 연관된 작업만 수행하고 연관성 없는 작업은 다른 객체로 위임하면 응집도가 높다고 말합니다. 자율적인 객체를 통해 결합도를 낮추고 응집도를 높일 수 있습니다.

절차지향에서는 데이터와 프로세스를 구분해서 수동적으로 일을 처리합니다. 객체지향은 데이터를 사용하는 프로세스가 객체 내부에 함께 존재합니다.

두 방식의 근본적인 차이는 책임의 이동입니다. 절차지향에서는 프로세스를 실행하는 부분에서 전체의 작업을 도맡아합니다. 객체지향에서는 각 작업을 개별 객체에게 위임시켜 스스로 일을 책임집니다. 즉 데이터를 사용하는 프로세스가 별도의 객체에 있다면 절차형일 확률이 높습니다.

실생활에서 무생물은 수동적인 존재이지만 객체지향에선 능동적인 존재가 됩니다. 사람인 것처럼 의인화해서 무생물도 자율적으로 행동해야 합니다.

• 오늘 완성해야하는 기능을 구현하는 코드
• 동시에 내일 쉽게 변경할 수 있는 코드

변경을 수용한 설계가 중요한 이유는 요구사항은 항상 변경되기 때문입니다. 개발을 시작하는 시점에서 모든 요구사항을 만족시키는 것은 불가능에 가깝습니다. 또 버그는 변경할 때 추가될 가능성이 높습니다. 버그가 발생하는게 두려워 변경하지 않으려할 수 있기에 유연한 설계가 필요합니다.